Add Book to My BookshelfPurchase This Book Online

Chapter 7 - Building a TCP/IP Router-Based Network

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Reducing Manual Configuration
So far we have discussed issues related to internetwork design and configuration that have assumed all devices have an IP address configured. Manually configuring IP addresses for each host router and PC implemented on a large internetwork can be a time-consuming task. There are, however, some mechanisms such as RARP, BOOTP, and DHCP that can reduce this burden.
RARP: Reverse Address Resolution Protocol
Reverse Address Resolution Protocol (RARP) converts MAC addresses into IP addresses, which is the reverse of what the regular ARP protocol does. RARP originally was designed for supplying IP addresses to diskless workstations in an Ethernet environment. A diskless workstation has no hard drive on which to locate its IP address; it does, however, have a unique MAC address on its network card. When the diskless workstation boots up, it sends out a layer 2 broadcast (all 1s in the destination MAC address). When a server running RARP receives one of these broadcasts, it looks up a table (in a Unix machine, this table is usually located in the /etc/ethers file) and supplies the IP address that the table associates with the MAC address back to the machine originating the broadcast.
The functionality of RARP was enhanced by the bootstrap protocol BOOTP, and later the Dynamic Host Configuration Protocol. DHCP is a superset of what BOOTP does. BOOTP and DHCP are implemented with both client and server software, the former to request IP configuration information, and the latter to assign it. Because DHCP was developed after BOOTP, DHCP servers will service IP configuration information to BOOTP clients.
DHCP: Dynamic Host Configuration Protocol
Assuming that a DHCP server exists on the same local segment as a client machine needing to find its IP configuration via DHCP, the client machine will issue a broadcast on startup of the IP protocol stack. This broadcast will contain the source MAC address of the workstation, which will be examined by the DHCP server.
A DHCP server can operate in one of three modes, the first of which is automatic assignment, which permanently assigns the one IP address to a given workstation. This is appropriate for environments with plenty of available addresses for the number of hosts on the network, typically one that is connecting to the Internet via a Network Address Translation machine of some kind.
The second mode, dynamic addressing, allocates IP addresses to hosts for a predetermined amount of time. In this configuration, IP addresses are returned to a pool of addresses that can be reassigned as new hosts become available and old hosts are retired. Dynamic addressing is most appropriate for sites that have a limited address space and need to reallocate addresses as soon as a host is retired. Typically, these sites are using InterNIC-assigned addresses and are connected directly to the Internet.
The third mode for DHCP, manual mode, uses DHCP merely as a transport mechanism for a network administrator to manually assign IP configuration information to a workstation. Manual mode is rarely used for DHCP implementations.
DHCP is the most popular method of automatically assigning IP addresses, and is the default method used by Microsoft products. DHCP has been put forward by many as a method to simplify renumbering of an internetwork, should that become necessary for any reason. It would be much simpler to change the IP information on a few dozen DHCP servers than on hundreds or thousands of hosts. The downside is that there is no built-in cooperation between DHCP and DNS (discussed in the next section). Obviously the DNS information will become useless if a host is using an IP address different from the one listed in the DNS database.
Next we'll discuss how to centrally manage host names, then cover a Cisco product that can co-ordinate DHCP and DNS activities.
Centrally Managing Host Names
So far, we have only discussed translation of host names to IP addresses via reference to a host table. On a large internetwork, distributed host files on numerous hosts become burdensome to manage. Imagine moving a host from one subnet to another and having to manually alter hundreds of host files located around the internetwork to reflect that change.
Fortunately, there is a service called Domain Name Service (DNS) that enables you to centrally manage the mapping of host names to IP addresses. DNS does not rely on one large table, but is a distributed database that guarantees new host information will be disseminated across the internetwork as needed. The major drawback of DNS is that there is no way for a new host to advertise itself to DNS when it comes online. Although DNS will distribute information throughout an internetwork, a host initially must be manually configured into a central DNS machine when the host first comes online.
You have to configure each host to use DNS in preference to a host file for name resolution, and supply the IP address of the DNS server that must be referenced. When a DNS server receives a request for information regarding a host it does not currently know about, the request is passed on to what is known as an authoritative server. Typically each domain has an authoritative server that supplies answers to several DNS servers that each have a manageable number of hosts to service. A previous version of DNS was called nameservice. Nameservice and DNS are differentiated by the port numbers they use; nameservice uses port number 42 and DNS uses 53.
If your internetwork is going to accommodate more than a dozen or so hosts, it is worth implementing DNS. In the following discussion, we will examine in overview how DNS is implemented on the Internet. It is a good model for illustrating how DNS can be scaled to very large internetworks.
A DNS hierarchy is similar to the hierarchy of a computer’s file system. At the top is the root domain consisting of a group of root servers, which service the top-level domains. These top-level domains are broken into organizational and geographic domains. For example, geographic domains include .uk for the United Kingdom, .de for Germany, and .jp for Japan. Normally no country-specific domain is associated with the United States. The U.S. top-level domain is split into organizational groups, such as .com for commercial enterprises, .gov for government agencies, and so forth. Some of the top-level domains for the United States are shown in Fig. 7-8.
Figure 7-8: Top-level domains for the Internet
Just as you can locate files in a file system by following a path from the root, you can locate hosts or particular DNS servers by following their paths through the DNS hierarchy. For example, a host called elvis in the domain stars within the commercial organization oldies is locatable by the name elvis.stars.oldies.com.
In some ways the operation of DNS can be thought of as similar to the way routing tables work for routing packets through an internetwork. No single DNS server has a complete picture of the whole hierarchy; it just knows what is the next DNS server in the chain to which it is to pass the request. A particular domain is reachable when pointers for that domain exist in the domain above it. Computers in the .edu domain cannot access computers in the .work.com domain until a pointer to the DNS server of the .work subdomain is placed in the servers of the .com domain. A DNS database in the .com DNS servers contains name server records that identify the names of the DNS servers for each domain directly under the .com domain.
Let's clarify this by considering an example. Supposing a domain under .edu has been created called .univ and a domain under .com has been created called .work (illustrated in Fig. 7-8). Now, a computer in the .univ domain (let's say it is named vax) needs to contact a machine in the .work.com domain (which is called sun). The task to accomplish here is to provide to the machine vax.univ.edu, the IP address of sun.work.com. The process to complete this task is as follows:
  The vax.univ.edu host is configured to have its DNS server as the machine with IP address 201.1.2.3, so it sends a DNS request to that IP address. This computer must be reachable by vax.univ.edu.
  Host vax.univ.edu receives a reply stating that a machine named overtime.work.com has all DNS information for the .work.com domain, and the IP address of overtime.work.com is included in the reply.
  Host vax.univ.edu will then send a query to the IP address of overtime.work.com for the IP address of sun.work.com.
  The computer overtime.work.com replies with the requested IP address, so vax.univ.edu can now contact sun.work.com.
DNS is normally implemented on a Unix machine via the Berkeley Internet Name Domain (BIND) programs. BIND has two elements, the Name Server and the Resolver. The Resolver forms queries that are sent to DNS servers. Under BIND, all computers run the Resolver code (accessed through libraries). The Name Server answers queries, but only computers supplying DNS information need to run the Name Server.
On a Unix machine running BIND, the named.hosts file contains most of the domain information, converting host names to IP addresses and also containing information about the mail servers for that particular domain. DNS and BIND are subjects that justify a complete book in their own right. The preceding discussion is intended to give a very brief overview of how DNS can simplify administration of a large TCP/IP-based internetwork. If you want to set up DNS on your network (I recommend that you do), refer to the publication DNS and BIND by Cricket Liu and Paul Albitz, published by O'Reilly and Associates.
If you can configure DNS and either BOOTP or DHCP, your life as administrator of a large TCP/IP-based internetwork will be much simpler.
Integrating the Operation of DNS and DHCP
Cisco have released a product called the Cisco DNS/DHCP Manager, known as the CDDM for short. What we'll look at in this section is an overview of the system components, how DNS and DHCP are coordinated by the CDDM, coping with multiple logical networks on the same physical wire, and creating a new domain.
CDDM System Components.     The key to understanding how this integration works is to realize that DHCP is the primary tool that allocates IP addresses and updates DNS database entries with new IP address information. DNS is the passive receiver in this integrated product. The CDDM consists of a Domain Name Manager, which is a graphical DNS management tool that runs on the usual platforms of Solaris, HP/UX and AIX, and a DHCP server that does the dynamic updating of DNS with IP addresses assigned to DHCP clients.
Using a graphical tool like the DNM to update your DNS configuration, rather than manually editing ASCII zone transfer files has many benefits. Notably, the Domain Name Manager browser reduces common configuration errors by checking the syntax of each new entry. The Cisco DHCP server automatically updates the Domain Name Manager with the IP address and domain name of the new nodes on the network. The Domain Name Manager then propagates this information to DNS servers on the network. As such, the Domain Name Manager replaces an organization's existing primary DNS server and becomes the source of DNS information for the entire network.
Many hosts that are accessed via the World Wide Web use information in DNS to verify that incoming connections are from a legitimate computer. If both an A record and a PTR record are registered for the incoming client, the server assumes that a responsible network administrator has assigned this name and address. If the information in the DNS is incomplete or missing, many servers will reject connections from the client.
To simplify the process of bringing a new host on-line, the Cisco Domain Name Manager automatically adds the PTR record into the DNS configuration. The PTR record is the mapping between an IP address and a DNS name and is also known as reverse mapping. Omitting the PTR record is one of the most common mistakes when managing a DNS server.
For networks that use NT extensively as the applications and file/print services server, the CDDM provides enhanced TCP/IP services for NT that are sorely lacking in the base product. These include NTP for time synchronization, TFTP to load binary images and configuration files to network devices including routers and a syslog server to log error messages from network devices over the network.
More frequently these days, organizations are deploying Ethernet switches that allow a reduction in network segment traffic, along with a flattening of the IP addressing scheme. The main benefit of this is to use fewer router ports in an internetwork, which produces a cost saving. Problems have occurred with traditional devices when DHCP is to be implemented on a segment that has more than 254 hosts and class C addressing is in use. This is becoming more common, as address depletion of registered Internet addresses results in blocks of class C addresses being the only ones available.
It is feasible to have multiple class C networks assigned to the same physical segment, however, this does cause difficulties for many DHCP servers. These DHCP servers expect one physical segment to be associated with only one network number. By contrast, the Cisco DHCP server supports address pools that contain multiple logical networks on the same physical network. Additionally, the Cisco DHCP server can combine pools of IP addresses from multiple networks into a single large pool of addresses. The DHCP server also supports BOOTP to enable you to manage BOOTP and DHCP from one server.
The Specifics of CDDM Operation.     Having overviewed the operation of CDDM, let's look in more detail at how it is set up. As previously stated, the cornerstone of the CDDM is the Domain Name Manager (DNM) Server, which lets you manage zone data, specifically, host names and addresses from across a network.
The zone data originates in ASCII text files called "zone files," which primary name servers read on start-up and propagate to "secondary" name servers via zone transfers.
Many network managers choose to advertise only their secondary name servers, and dedicate their primary name servers to perform zone transfers. The CDDM supports this approach by assigning zone transfer and name resolution to separate servers.
The DNM server takes over the role of zone transfers but leaves the role of name resolution to DNS servers. DNS servers configured as "secondary" name servers can obtain zone transfers from a DNM, but the DNM server must not be advertised as a name server with NS (name server) records because it does not resolve names.
Every time you modify the DNM server's database, the DNM server increments the appropriate zone serial numbers so that the corresponding secondary name servers can detect a change in the zones for which they are authoritative and request zone transfers.
Normally, you could not run a DNM server and a DNS server on the same host because both servers listen on port 53 for zone transfer requests. The CDDM, however, includes an enhanced DNS server that can request zone transfers over any port. The Cisco DNS server is based on BIND 4.9.5, so you can both use existing zone files and receive new zone data from your DNM server. Cisco's on-line documentation uses an example of port 705 to receive data from a DNM server.
The DNM operates as a client server application on a network. The DNM server maintains a single database instead of multiple zone files and communicates updates to clients via a proprietary protocol independent layer, enabling you to manage any DNM server from any host running a DNM client.
A special DNM client is called the DNM Browser which simplifies everyday DNS management tasks such as adding new hosts or changing host addresses and lets you configure DNM servers from remote hosts. The DNM Browser presents a view of the domain name space in an outline-style layout that makes it easy to browse through domains.
The DNM Browser communicates with DNM servers over TCP/IP, so you can manage DNS names from remote hosts. On UNIX platforms, the DNM Browser is an X client. On Windows NT and Windows 95, the DNM Browser is a native Windows application.
As you grow your network, the DNM browser will automatically:
  Modify inverse mappings when you add new hosts, and propagates name server records appropriately when you create new subdomains
  Check for domain name conflicts
  Finds available IP addresses on specified networks
  Import existing DNS zone files and export zone files and UNIX-style host tables
To manage a DNM server's database from a DNM client, you must have a DNM server account. When you connect to a DNM server you must supply a valid user name and password. If you use the DNM Browser, you enter your account information when prompted. You can use the DHCP/BootP server to manage the DNM server, however, you must configure the DHCP/BootP server with valid account information to do so.
The previously mentioned Cisco DHCP/BootP server can be configured to behave as a DNM client, which allows you to automatically coordinate names in DNS with names in the DHCP/BootP server's database.
Note the DHCP/BootP server can only update the DNM server with information from its DHCP database. The DHCP/BootP server does not propagate information from its BootP database to the DNM server.
Traditionally, DHCP and BootP databases have been managed independently of the DNS. With most DHCP and BootP servers, every time you add a host entry to the DHCP database, you must also add corresponding domain names for the host: one in the parent domain and another in the in-addr.arpa domain.
The Cisco DHCP/BootP server and DNM server eliminate the need to manually coordinate the DNS with your DHCP or BootP databases by dynamically updating zones dedicated to your DHCP clients.
One point to be wary of if you are thinking of implementing this technology in a very large network is that the DHCP/BootP server only accommodates a single DNM server, even if it manages hosts in multiple domains. If your network requires multiple DNM servers, you must configure a unique DHCP/BootP server for each DNM server. Make sure that the DNM server is authoritative for both your dynamic host names and the corresponding addresses via the inverse domains under the in-addr.arpa domain. Of course if your network requires more than one DHCP/BootP server, make sure they each use a separate, unique domain.
One implementation recommendation is to define a dynamic domain for DHCP clients. The DHCP/BootP server lets you choose the name of a domain to which it will add domain names for DHCP clients. For example, if your domain is best-company.com, you might reserve the domain, dhcp.best-company.com, for DHCP clients. All clients then acquire host names such as machine1.dhcp.best-company.com when they accept DHCP leases from your DHCP/BootP server.
The DHCP/BootP server can support only one dynamic domain, but the DNM server can accommodate multiple DHCP/BootP servers if they are configured for different dynamic domains.
If you do implement a dynamic domain, you should avoid adding names to this domain by any means other than by the DHCP/BootP server. If you manually add names to a dynamic domain, the DHCP server may delete them, depending on how you configure it.
There are two methods of specifying how the DHCP/BootP server chooses names for DHCP clients.
The first method is to create a fixed set of host names based on the DHCP database entry name for each IP address pool and propagate those names to the DNM server every time the DHCP/BootP server starts. If a host already has the entry name (for example, test), subsequent hosts are assigned the entry name with a number appended to it (for example, test1 or test2). Each time you start the DHCP/BootP server, it checks its list of outstanding leases and, if necessary, it updates the DNM server to rebuild the dynamic domain, even if you did not change any of the corresponding DHCP entries.
The second method will let the DHCP client request a host name, and add a new domain name to the DNM server when the client accepts the DHCP server's offer. If the client does not request a name, the DHCP/BootP server assigns a name based on the DHCP database entry much the same as method 1. The DHCP/BootP server only adds a name to the dynamic domain when a client accepts a lease. Similarly, the DHCP/BootP server only deletes a name from the dynamic domain when the corresponding lease expires.
Supporting Multiple Logical Networks on the Same Physical Network.     The DHCP/BootP server lets you create a pool of IP addresses that spans multiple logical subnets, using the sc (subnet continuation) option tag, a functional extension of DHCP. This option tag is useful when you need to pool addresses from different networks, such as two Class C networks or a Class B and a Class C network.
For example, suppose you need to offer a pool of 400 addresses and your network is composed of two Class C networks. The sc option tag lets you combine the two subnets and put all 400 addresses in the pool.
Most IP routers let you forward DHCP/BootP requests received on a local interface to a specific host. This forwarding feature is often called BootP helper or BootP forwarder. On Cisco routers, you can control BootP forwarding with the Cisco IOS commands ip helper-address and set dhcp relay. The action of these commands is to pick up a UDP broadcast on a local segment and direct them to the IP address specified in the ip helper-address command.
When routers forward DHCP/BootP requests, they place their own IP addresses in the DHCP/BootP packet in a field called "GIADDR." The router inserts the IP address of the interface (called the "primary" interface) on which it received the original DHCP/BootP request. The DHCP/BootP server uses the address in the GIADDR field to determine the IP subnet from which the request originated so it can determine which pool of addresses to use before allocating an IP address to the DHCP/BootP client.
When you run multiple IP network numbers on the same physical network, you typically assign multiple IP addresses to a router interface by use of the secondary IP address interface configuration command. Because the DHCP/BootP server only allocates addresses based on the GIADDR field, and because it only receives the router's primary address in the GIADDR field, you must configure the DHCP/BootP server to associate the other network addresses with the primary subnet using the Subnet Continuation parameter (sc option tag). You can specify an arbitrary number of secondary address pools in the DHCP configuration, to make all addresses in the primary and secondary entries available to DHCP clients on the corresponding network segments. DHCP entries that contain sc option tags must appear after the entry for the subnet they specify in the DHCP configuration editor's entry list.
Creating a New Domain.     To complete our discussion of the CDDM and its components, we'll look at the specifics of creating a new domain. Clearly as new revisions of the CDDM these steps will change, but the following procedure should give you a good feel for what it takes to operate the CDDM.
First we'll create a test domain using the DNM Browser, then we'll configure the DNS server as a secondary name server for the test domain. Next we'll configure the Syslog service for troubleshooting DHCP and BootP service, and look at how to manage the DNM server via the DHCP server and finally how to configure the BootP service.
So, let's get started by using the DNM Browser to create and propagate the best-company.com domain.
Using a Windows NT system as an example, double-click the DNM Browser icon in the directory in which you installed CDDM, and choose DNM Browser from the Windows Start menu.
Next, in the Authentication for local host dialog box, enter admin in both the Username and in the Password fields, and click OK.
Next, choose Add from the Edit menu in the DNM Browser main window and enter best-company.com in the Fully Qualified Name field. Check that the Modify records box is enabled, and click OK. When the Modify Resource Records window appears, select the Authority tab. Click Reset to Suggested Values, at which point the DNM Browser inserts a set of suggested SOA values. You can then change the Primary Name Server field to name1.best-company.com. Once this is completed, change the Responsible Person Mailbox field to my_e-mail@best-company.com (insert an appropriate e-mail address for my_e-mail).
Now, click the Name servers "+" button in the Name Server Records group, type name1.best-company.com in the Name servers field, and click OK. The best-company.com domain should now appear in the DNM Browser.
Next choose Add from the Browser's Edit menu, and in the Fully Qualified Name field of the Add dialog box, type name1.best-company.com, then make sure that the Modify records box is enabled, and click OK.
In the Basic tab of the Modify Resource Records window, click the "+" button in the Address Records group. In the Add IP Address dialog box, type 172.45.1.1 (or whatever IP address is appropriate) in the Starting IP Address field, and click OK. When the Modify Resource Records dialog box is active again, click OK, name1 now appears in the DNM Browser.
You can add a host (called for example host.best-company.com) by repeating the above. To refresh the DNM Browser's display, choose Reload from the Edit menu. The address 172.45.1.2 should be automatically assigned.
Note that although the DNM server automatically creates the "reverse" pointer records, it does not create a Start of Authority (SOA) record. To add the SOA records for the 1.1.10.in-addr.arpa domain, make sure 1.1.10.in-addr.arpa is selected in the DNM browser window, then choose Modify from the Edit menu.
Once the Modify Resource Records dialog box appears, select Authority in the Modify Resource Records window, and click Reset to Suggested Values. The DNM Browser inserts a set of suggested SOA values.
Next you must change the Primary Name Server field to name1.best-company.com, change the Responsible Person Mailbox field to an appropriate e-mail address and click the Name servers "+" button in the Name Server Records group to enter name1.best-company.com, then click OK. The icon for 1.1.10.in-addr.arpa in the DNM Browser now indicates the new SOA record with a red triangle.
There are lots of other tasks associated with the CDDM that you can complete, like setting up a secondary system. As you gain familiarity with this very useful tool, you can expand the scope of the CDDM activities to largely automate the assigning of hostnames and IP addresses on your network.

 


 
Books24x7.com, Inc © 2000 –  Feedback